1. Field of the Invention
The present invention relates generally to the field of computer software, and more particularly to a system and method for automatically generating a script for testing software (e.g., application software, etc.).
2. Background of the Invention
It is often desirable for a test user to be able to test application software (or other types of software) for a variety of reasons. A test user is one who tests the software. For example, a test user may want to test the software just before it is commercially released in order to remedy any remaining bugs. This will ensure that an end user will be using software with as few bugs as possible. An end user is one who uses the software, but is not necessarily involved in testing the software.
A test user may also want to test the software during various stages of development. Testing during development can assist in finding bugs as well. Testing during development can also assist in streamlining and improving various aspects of the software, including the operation, user-friendliness, etc. As testing occurs throughout a design cycle, the software can be modified accordingly. Implementing an iterative process of repeatedly testing and refining the software is typically much more efficient than completing the design before doing any testing.
Referring to FIG. 1, one prior art system 100 is shown for testing application software 102. Application software 102 is defined by code stored as part of data 104. A manned computer system 106 is used to test application software 102. A test user sits at manned computer system 106 and attempts to exhaustively test application software 102 manually using a graphical user interface (GUI) or otherwise. This is a very inefficient brute force method of testing application software 102. For complex application software 102, there may be thousands of pages (or screens) that may possibly be displayed to a test user. It may take the test user hundreds of hours to test the application software. Even then, one cannot be certain that application software 102 has been tested adequately. And if further testing is desired the entire process might have to be repeated in whole or in part.
Referring to FIG. 2, another prior art system 200 is shown for testing application software 102. Application software 102 is again defined by code stored as part of data 104. Manned computer system 106 is used to test application software 102. A test user sits at manned computer system 106 and attempts to exhaustively test application software 102 manually using a GUI or otherwise. A record engine 208 is configured to record the test user's navigation through application software 102 as the test user is manually testing application software 102. This testing will often involve entering data into application software 102 as well. The data is stored as part of data 104.
Record engine 208, in turn, creates record script 210. This process is purely a recordation of the test user's activity with respect to application software 102. Record script 210 is used in conjunction with execution engine (or playback engine) 212. Record script 210 simply instructs execution engine 212 to simulate the test user's testing with respect to application software 102. Thus, execution engine 212 simulates the many arduous hours the test user spent manually attempting to thoroughly test application software 102. Nevertheless, this is still a very inefficient method of testing application software 102. As previously mentioned, there may be thousands of pages that may possibly be displayed for complex application software 102. It may take the test user hundreds of hours to manually test application software 102. Even then, the test user cannot be certain that application software 102 has been tested adequately. Again, if further testing is desired the entire process might have to be repeated in whole or in part. For example, one may want to quickly verify changes, new enhancements and fixes to be released. The prior art attempts do not allow for rapid testing under these circumstances.
Another prior art attempt at testing application software also includes using a script to automate the testing process. These scripts are run and they simulate a test user's manual testing of application software 102. However, these scripts are hardcoded (i.e., manually created) as opposed to playing back a recorded session. Yet another prior art attempt includes hardcoding scripts to randomly perform commands on application software 102 to ensure that application software 102 will not crash. The creation of these scripts is very expensive and time-consuming requiring much programmer time and/or much test user testing time. Moreover, if application software 102 is modified, the hardcoded scripts often must be modified by hand as well.